運用・監視っていう対象がよく分からないのでまとめてみた

運用・監視っていう対象がよく分からないのでまとめてみた

Clock Icon2019.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます、もきゅりんです。

この界隈に生息していると耳にする「運用・監視」。(聞きませんか?)

概念は広いし、抽象的だし、明確な定義があるわけでもなさそうなので、自分は今ひとつ何をどこまで考えるものなのかよく分かっていませんでした。

でもよく分からないまま使うのは、気持ちが悪い。

ということで、とりあえず自分がまとめた一例をとりあえずブログにしておきます。

運用・監視とは

まず「運用・監視」という用語ですが、運用という概念の中に監視が含まれているため、そもそも並列で使うものではなさそうです。

耳にしたこともあるし、自分も特に気にせず使っていましたが、「運用」で良さそうです。

「監視」については、後述します。

運用ですが、機能・役割によっていくつかに分別ができるようです。

自分が確認した限り *1、とりあえず下記3つの機能・役割で大きく分けられそうです。

なお、あえて自分が理解しやすい機能名に変換しています。

  • 統括(全体管理と設計)
  • ユーザー窓口
  • 管理・開発
機能 役割 業務内容イメージ
統括(全体管理と設計) 以下2つの業務の統括管理、推進を担う。 ・運用の全体設計
・運用情報統制
・インシデント対応マニュアル
・リカバリプランの策定/実行フローマニュアル
・定期報告/レビュー/改善アクション
・新サービス/機能の共有
ユーザー窓口 エンドユーザーへのサポートやヘルプ対応をする。 ・システム利用者管理(組織/会社/担当者など)
・サポートデスク対応
・インシデント情報提供
管理・開発 実際に継続的にプロダクトを開発、テストしてサービスを提供する。また利用しているリソースを管理する必要もある。 ・ パッチ運用
・ ジョブ設計監理
・ バックアップ管理
・ 監視
・ 運用アカウント管理(IAM,Organizationsなど)
・ CI/CD (コード品質/コードテスト/ビルド・デプロイなど)
・ 保守(AMI/インスタンスタイプ/ミドルウェアバージョン管理など)

具体的な業務内容としてはこのようなものかと思いますが、「運用」と使われた用語が、文脈上、何をどこまで指すのかは、よく組織内、関係者内で確認する必要があると思いました。

若干、目的と趣旨が異なるのですが、AWSを利用する上では欠かせない視点である

AWS Well-Architected Framework ヒアリングシート(日本語版)

とも上記表とを見比べました。

Well-Architected Frameworkとの関係

いかんせん項目が多いので、ここですべて洗うことはできませんが、基本的には、上記表における「管理・開発」チームでの業務範囲に当てはめていけるものだと思います。

ただ、一部分として、それ以外の管理下にしても良さそうな項目はあると思いました。

特に全体的な規定やインシデント、リカバリプランのようなものは統括で管理する統制すべきなのかな、と考えます。

また、新しいサービスや機能の共有、コスト最適化などは統括で行っても良い気がしました。(コスト最適化は部分最適化になりがちなため)

監視について

運用の一要素である、監視については、下記のように階層構造で考えると分かりやすいと考えました。

なお、一般的な閲覧用のサイトを想定しており、階層のあり方はサイトの用途によって異なること、一つ一つの階層において、さらに階層化できるものであり、あくまで一例です。

  • (1) サービスのKPIは何か?
    • (2) サービスを構成する要素を階層/役割・機能で細分化して、取得するメトリクス/ログを考える
      • フロントエンド
      • アプリケーション
      • インフラ基盤
        • サーバの機能・役割で分別して必要なデータを取得する (e.g. Web, DB, Cacheなど)
          • OSメトリクス
        • ネットワーク
      • セキュリティ
    • (3) メトリクスとログのどちらが有効か
      • 何を取得するか・できるか/どんなパフォーマンスを期待しているか/目標数値はどれくらいか
      • 保存場所/ライフサイクル/分析をどうするか
    • (4) 何をアラートするか
      • 早急にアクションが必要なものに限定する設定

ログやメトリクス取得の目的は、パフォーマンス計測と事象の記録であり、立ち返るべきは、何のために、どんなログ/メトリクスを取得するのか目的を明確にすることです。

その目的において、システムの各機能、各役割において、どこがボトルネックなのかを切り分けて洗い出せるように設計します。

もちろん、細分化すればするほど管理コストが増大していくので、目的に対するメリットとコストとのデメリットを天秤にかけて設計する必要があると考えられます。

閲覧が主目的のサイトであれば、まずはサイトが閲覧できていること、体感表示速度を計測して継続的に改善するためのメトリクスとログ取得が最低限となります。

最後に

「運用・監視」から「運用」と「監視」とをまとめてみました。

「運用」は、新しいサービスや技術が現れるために、どんなサービスを用いて、何をどこまでを考えるかをうまく定義することができず、今ひとつ明確にならないものになってきてしまうという背景もあるのかな、と感じました。

ただ、個人的にはこのようにまとめたことで理解は進んだ気がします。

以上です。

どなたかのお役に立てば幸いです。

参考:

脚注

  1. 参考を参照

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.